|
|
|
|
|
|
|
federal government to comply with laws that govern bank transactions involving cash amounts of more than $10,000. This scenario, then, is a different instance (or customization) of the use case Open Account. It's certainly different than opening an account with less than $10,000 in cash. Use case scenarios (and their corresponding sequence diagrams) describe each path (or instantiation) the use case can take. |
|
|
|
|
|
|
|
|
Now you should re-examine the use-case model in Figure 2.1. This use-case model is the end result (or artifact) of your initial analysis process. At this point, you're proud to have completed your first use-case modelso proud, in fact, that you race off to display your stroke of genius to the domain experts (expert users or managers) who own the business process(es) behind this model. |
|
|
|
|
|
|
|
|
At first, the experts are pleasantly surprised and impressed. They brag about you to a teller who will use the system. The teller is pleased that progress is being made, but he notices something missing. He needs to be able to look up the customer's account information before closing the account to make sure that the customer doesn't owe money to the bank and is authorized to close the account. Also, he might want to view the account information to answer a customer's questions. |
|
|
|
|
|
|
|
|
In the traditional analysis process, you would have to restructure the data flow diagrams in various places and redo the program code (because you probably already started coding the requirements). This rework usually involves patching in the new functionality, meaning that new global functions are inserted in some module somewhere or the code is tucked behind a button on a form. Some programmers are not even this nice; they might growl that the requested feature was not in the original specs and therefore cannot be incorporated. |
|
|
|
|
|
|
|
|
With the object-oriented analysis approach, such crucial change requests are easily incorporated, provided they fit naturally within the context of your problem domain. Clearly, the viewing of account information is a mission-critical feature (as each of the project's stakeholders agree) and, as such, needs to be added to your use case model. Because you have done no coding, the only extra time you need is for inserting another use case into your model and updating the problem statement (another often overlooked step). Figure 2.4 shows your updated problem statement. Figure 2.5 represents the updated use case model. In Figure 2.5, I've added a use case, View Account Information, that captures the activity in which the teller needs to view his or her customer's account information. |
|
|
|
|
|
|
|
|
As alluded to earlier, a sequence diagram (also known as an interaction diagram or event trace diagram) is a diagrammatic representation of a specific instance of a use case. This specific use case instance is called a scenario. A scenario is a sequence of steps taken by |
|
|
|
|
|